app/lanes/mempool.go (1)

Line range hint 33-70: Consider adding validation for the extractor parameter.

While the validation logic is well-organized and comprehensive for ratio and txEncoder, the extractor parameter should also be validated to ensure it's not nil, as it's a critical component for transaction processing.

 func validateMempoolConfig(ratio math.LegacyDec, txEncoder sdk.TxEncoder) error {
     if !ratio.IsPositive() {
         return errors.New("mempool creation: ratio must be positive")
     }
     if ratio.GT(math.LegacyOneDec()) {
         return errors.New("mempool creation: ratio must be less than or equal to 1")
     }
     if txEncoder == nil {
         return errors.New("mempool creation: tx encoder is nil")
     }
     return nil
 }

 func NewMempool[C comparable](
     txPriority blockbase.TxPriority[C], extractor signer_extraction.Adapter,
     maxTx int, ratio math.LegacyDec, txEncoder sdk.TxEncoder,
 ) (*Mempool[C], error) {
+    if extractor == nil {
+        return nil, errors.New("mempool creation: signer extractor is nil")
+    }
     if err := validateMempoolConfig(ratio, txEncoder); err != nil {
         return nil, err
     }

app/lanes/proposals.go (3)

165-167: Avoid logging nil errors in logAndAppend

In logAndAppend, the error is logged even when err is nil, which could lead to misleading log entries. Check if err is not nil before including it in the log.

Apply this diff to conditionally log the error:

 func (h *DefaultProposalHandler) logAndAppend(message string, tx sdk.Tx, err error, txsToRemove *[]sdk.Tx) {
-    h.lane.Logger().Info(message, "err", err)
+    if err != nil {
+        h.lane.Logger().Info(message, "err", err)
+    } else {
+        h.lane.Logger().Info(message)
+    }
     *txsToRemove = append(*txsToRemove, tx)
 }

---

142-144: Correct the transaction priority error message

The error message in validateTxPriority might be misleading. When priority == -1, it means the current transaction has lower priority than the previous one. The message should reflect that to avoid confusion.

Update the error message as follows:

 return fmt.Errorf("tx at index %d has lower priority than tx at index %d", index, index-1)

---

122-124: Ensure transactions exceeding size limits are handled consistently

In validateTxEligibility, when a transaction causes updatedSize to exceed limit.MaxTxBytes, it logs the issue but does not append the transaction to txsToRemove. This could result in the transaction being reconsidered in future proposals. Consider appending the transaction to txsToRemove for consistency.

Apply this diff:

 return false
+ *txsToRemove = append(*txsToRemove, tx)

app/ante/accnum/account_number.go (1)

51-53: Handle potential errors when setting the new account number

In AnteHandle, when setting the new account number using authKeeper.AccountNumber.Set, you wrap the error with sdk.ErrInternal. Since sdk.ErrInternal is deprecated, consider using sdkerrors.ErrInvalidRequest or another appropriate error type from sdkerrors.

Update the error handling as follows:

 if err := authKeeper.AccountNumber.Set(gasFreeCtx, newAccountNum); err != nil {
-    return ctx, sdk.ErrInternal.Wrapf("failed to set account number: %v", err)
+    return ctx, sdkerrors.Wrapf(sdkerrors.ErrInvalidRequest, "failed to set account number: %v", err)
}

app/lanes/mempool.go (1)

Line range hint 155-182: Consider extracting constants and error messages.

The validation logic is solid, but would benefit from better organization:

• Define error messages as constants
• Consider creating a separate type for lane limits configuration

+const (
+    ErrTxSizeExceeded   = "transaction size %d exceeds max lane size %d"
+    ErrTxGasLimitExceeded = "transaction gas limit %d exceeds max lane gas limit %d"
+    ErrNotFeeTx         = "transaction does not implement FeeTx interface"
+)

+type LaneLimits struct {
+    MaxTxSize    int64
+    MaxGasLimit  uint64
+}

 func (cm *Mempool[C]) AssertLaneLimits(ctx sdk.Context, tx sdk.Tx) error {
     maxBlockSize, maxGasLimit := proposals.GetBlockLimits(ctx)
-    maxLaneTxSize := cm.ratio.MulInt64(maxBlockSize).TruncateInt64()
-    maxLaneGasLimit := cm.ratio.MulInt(math.NewIntFromUint64(maxGasLimit)).TruncateInt().Uint64()
+    limits := LaneLimits{
+        MaxTxSize:    cm.ratio.MulInt64(maxBlockSize).TruncateInt64(),
+        MaxGasLimit:  cm.ratio.MulInt(math.NewIntFromUint64(maxGasLimit)).TruncateInt().Uint64(),
+    }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

 func buildAnteDecorators(options HandlerOptions, freeLaneFeeChecker func(sdk.Context, sdk.Tx) (sdk.Coins, int64, error)) []sdk.AnteDecorator {
     return []sdk.AnteDecorator{
+        ante.NewSetUpContextDecorator(), // Must be the first decorator.
         accnum.NewAccountNumberDecorator(options.AccountKeeper),
-        ante.NewSetUpContextDecorator(), // Must be the first decorator.
         ante.NewExtensionOptionsDecorator(options.ExtensionOptionChecker),
         moveante.NewGasPricesDecorator(),
         // ... remaining decorators
     }
 }

#!/bin/bash
# Search for multi-signer transaction patterns
ast-grep --pattern 'GetSigners($$$)' | grep -B 2 -A 2 'Signers'

#!/bin/bash
# Let's try a different approach to find multi-signer related code
# First, let's look for GetSigners method implementations
rg -A 5 "func.*GetSigners" 

# Also search for any mentions of multiple signers in comments or code
rg -i "multi.*signer|multiple.*signer"

# Look for test cases that might involve multiple signers
rg "test.*signer" -A 5

#!/bin/bash
# Let's search for any code or comments related to transaction signers
# Search for files containing GetSigners implementation
rg -p "func.*GetSigners" 

# Look for any test files or code related to transaction signing
rg -p "type.*Tx.*interface" -A 5

# Search for any comments or documentation about transaction signing
rg -i "transaction.*sign|tx.*sign" 

#!/bin/bash
# Let's search for transaction signing related code in the app directory
rg -p "type.*Signer" app/
rg -p "interface.*Signer" app/
rg -p "struct.*Signer" app/

# Look for any documentation or comments about transaction signing
rg -i "transaction.*signer|tx.*signer" app/ -A 3